-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Fix BABE epochs-transition logic on the core side #3620
Conversation
ee2d7dc to
95846ca
Compare
d4cef45 to
d2d3942
Compare
a5a226e to
6d8a151
Compare
| ) | ||
| } | ||
|
|
||
| /// Write the cumulative chain-weight of a block ot aux storage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| /// Write the cumulative chain-weight of a block ot aux storage. | |
| /// Write the cumulative chain-weight of a block to aux storage. |
|
|
||
| /// Build an `is_descendent_of` function. | ||
| /// | ||
| /// The `current` parameter can be `Some` with the details a fresh block whose |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| /// The `current` parameter can be `Some` with the details a fresh block whose | |
| /// The `current` parameter can be `Some` with the details of a fresh block whose |
| // prune any epochs which could not be _live_ as of the children of the | ||
| // finalized block. | ||
| // i.e. re-root the fork tree to the earliest ancestor of (hash, number) | ||
| // where epoch.start_slot + epoch.duration >= slot(hash) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.inner.prune(hash, number, is_descendent_of) should work, but I'll verify again before merging this PR.
| // TODO: write tests within the scope of this module. | ||
| // | ||
| // 1. mock up an `IsDescendentOfBuilder`. Don't use the `Client` - these tests should be | ||
| // minimal and focused. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can mock an arbitrary tree like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would love to share that code!
| Ok(slots::start_slot_worker( | ||
|
|
||
| let epoch_changes = babe_link.epoch_changes.clone(); | ||
| let pruning_task = client.finality_notification_stream() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will only be started by validators this way and it must be run by all full nodes. That's why it was returned with the import queue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I realized that earlier today, which a bit too late. Still, I don't think that forcing the user to spawn a background task is friendly at all.
I'd rather have us prune implicitly every time we add an epoch, based on the finalized block.
| // TODO: block-import handles fork choice and this shouldn't even have the | ||
| // option to specify one. | ||
| // https://github.com/paritytech/substrate/issues/3623 | ||
| fork_choice: ForkChoiceStrategy::LongestChain, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we are authoring (before import), i.e. by this exact point, do we guarantee that nothing else gets imported in the meantime? I'm worried that we can author a primary block and won't reorg to it because in the meantime we might have imported a secondary block (with longest chain we would keep the secondary at the same height). The previous code was also susceptible to this kind of race condition if it exists.
In the meantime I read the code below and figured out that this logic was moved to BabeBlockImport which also takes care of the race condition issue.
|
|
||
| old_epoch_changes = Some(epoch_changes.clone()); | ||
|
|
||
| babe_info!("New epoch {} launching at block {} (block slot {} >= start slot {}).", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above, should these be downgraded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer these to go in the info logs since we won't get them that often (although due to forks we might get a couple ~duplicates at a time).
This is the counterpart to the initial type-definition work done in #3611 on the core side.
Rough overview of changeset:
SharedEpochChangeslogic out to its own module in a way that can be more cleanly testedNextEpochDescriptorabout the following epoch.